HCL
Skip to main content  
 
   


SPRTechnote


Error: "MT Collector: Error Indexing the Message Tracking Store..." and Crash on Message Tracking Collector (nMTC)

Technote Number: 1109707


Problem:
This issue was reported to Quality Engineering and has been addressed in Domino
6.0.4 and 6.5.2.

Excerpt from the Lotus Notes and Domino Release 6.0.4 and 6.5.2. MR fix list
(available at http://www.ibm.com/developerworks/lotus/):

MTC
SPR# BRIS5MLK8N - Fixed a problem where MTC (Message Tracking Collection)
crashes when out of virtual address space about once a week on Windows, when
running Domino as a service. This regression was introduced in 6.0.

Temporary workaround:

Deleting the MTDATA directory usually resolves the problem temporarily [refer
to the document "MT Collector: Error Indexing the Message Tracking Store: Full
Text Error - Failure to Init KV Filter" (#1138702) for more information], but
customers generally report a recurrence after about two weeks.

More permanent workaround:

The following workaround resolved the issue for at least one customer who was
crashing multiple times per week. After implementing this workaround, no crash
recurred during the 3 months it was monitored:

Set a Program document to purge the MTSTORE more frequently. Currently, the
default is every 30 days. You can increase this by running a Program document
to issue the following command:

tell mtc purge value

...where value is the maximum number of days. Set this to 7 (you may want to
start with 14 if 7 seems too aggressive), and then run this command via a
Program document once a week during off hours.

Another workaround if still an issue:

If the problem persists after adding the purge, the following may help:

Setup a Program document to run Updall -x once a week against the MTSTORE.NSF
(this will rebuild the full text index and keep it compact.)

Additionally, add the following NOTES.INI parameters:

PRIVATE_DPOOLSIZE_THRESHOLD=65536
PercentAvailSysResources=70

The first will force Domino to make requests directly to the O.S. for any
private memory allocations greater than 64K, helping to reduce fragmentation
(memory dumps seem to indicate this may be playing a part in the problem) and
improve utilization. The second parameter will reduce the initial size of the
buffer pool, allowing more memory to be available for individual tasks. The
second value can be set lower if necessary, but care should be taken as overall
performance may be affected.

Note that the default value for PRIVATE_DPOOLSIZE_THRESHOLD is 512K.
More >





  Document options
Print this document
Print view

  Search
Search Advanced Search


  Fix list views

 RSS feeds   RSS
Subscribe to the fix list

  Resources
Using this database
View notices

  HCL Support
HCL Support


    About HCL Privacy Contact